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Assumptions 


a) The 680x0 family is reaching the end of it’s lifetime. We 
already have indications in this direction from Motorola, essentially 
saying they aren’t likely to put the sort of effort that went into 
the ’040 in again, and that the ’050 etc will be relatively minor 
tweaks and usagage of extra transistors for bigger caches and/or 
more complete FPUs. The current 25Mhz ’040 only equals the low end 
of existing RISC cpus such as SPARC, Mips, and the 88000. It’s 
blown away by the mid- and higher-end RISCs (higher clocked of the 
above, rs/6000, HP snake, etc). Motorola will up the clock rate of 
the '040, bring the price down, and make minor mods, but there will 
be no fundamental improvements, and they will trail the mainstream 
RISCs. 


b) At the lower ends of the 680x0 family, the 68000 will likely 

be replaced by the ’EC020 or ’EC030 as the low-cost chip of choice 
eventually, though the 68000 will continue to be cheaper (sand). 

In a few years (3 to 5), however, the lower-end RISCs will start 

to be cost competitive and VERY performance/cost competitive. 
Already, an embedded version of the Mips R3000 is approaching $30 

in volume (ref: EET). A (very) rough guess is that in 3-4 years 
smaller RISCs (about the performance of the R3000) will approach sand 
prices, while the ’040 in any incarnation is highly unlikely to (too 
many transistors - on the order of 5-10 times as many as an R3000 
excluding caches). 


c) Realisticly, it would be VERY dangerous for this company to 
introduce a machine that was not software compatible with one of 
our existing machines. Chicken and egg problems are very large, as 
has been witnessed in the struggle to get the current acceptance of 
the Amiga, and our avoiding this as much as possible with CDTV and 
the C65. 


d) The Unix world is rapidly moving away from 680x0 and to the 
various RISCs. There’s a substantial market for 3rd party RISC 
machines (sparc clones, etc). We may have already largely missed 


‘the window for 680x0 Amiga Unix. 


Proposal 


I think we should start work now on developing a smooth transition 
to some RISC processor in the future. If done properly, this can 
even be fairly loosely coupled to the exact brand for quite some 
time, allowing the market to sort out the low-cost winner for us. 


In order to handle lc above, it should initially be a coprocessor 
board for A3000’s (and perhaps A2000’s/A1000+’s). Later built-in 
implementations would include some model of 680x0 processor (which 
one depends on price-level - low-end would probably have 68000 or 
perhaps ’EC020). This can be used to some degree to handle the 
compatibility issues. The 680x0 can be phased out at some point to 
cut costs. The reason for including it is that we’re unlikely to 
be sufficiently compatible with the existing software base without 
it (emulation probably won’t cut it for games). We could go to 
pure RISC with emulation, though this would cut down the percentage 
of programs that would run without recompilation/recoding. 


We can avoid tying ourselves to a specific RISC too soon by 
porting the AmigaOS via conversion of most assembler modules to 
Cy Some parts would have to remain assembler (interrupt handlers, 
for example). This would ease transition to a different RISC if 
our initial choice doesn’t win the low-price wars. However, we 
would still need to be careful in our initial selection, as changing 
will still be expensive and painful for us and our developers. 
Currently, I think the likely winners will be the Mips family and 
the 88000 family. I think for low-cost Mips will win, partially due 
to the volumes/interest at the low-end generated by the ACE 
consortium among others. 


A rough estimate is that 5 programmers full-time could get 
a minimal version (Alpha) of the OS up in 6-10 months, in Beta in 
an additional 10-12 months with 5 full time and 5 part time 
programmers. Beta would probably take 6+ months. As you can see, 
this adds up to two years, more likely 3. This puts us in the 
1995 timeframe, when (see above) the RISCs are likely to have become 
highly price competitive (especially on price/performance) at the 
high and mid-price ranges, perhaps even at the sand price range. 


I would estimate that this effort would require an additional 
4 to 6 extra programmers over what we currently need. Less would 
require stripping development resources from the work of keeping 
the AmigaOS up to date, handling new hardware (AAA), etc. 


One tool that might help in getting the initial version up would 
be a rough 680x0->C converter for initial passes. For production, 
the code would have to be cleaned up by a human. The toughest 
part of the problem would be the interactions between 680x0 and 
RISC in the same system. These might increase the requirements 
listed above in time (somewhat, 4-6 months total) and manpower 
(by say 1-3 people). A good 680x0->RISC assembler converter might 
do better, but requires locking ourselves into another processor, 
and with a few exceptions I doubt the performance difference is worth 
the cost. 


Having C and Asm versions of the same routines will add some 
to the normal maintenance costs to make duplicate changes. We 
might decide to take a ROM space/speed hit and move some of the 
Asm modules to C for all machines. 


3. Improvements/changes 


One possibly thorny issue is whether to change the design of the 
‘AmigaOS to any great extent. There are a number of minor flaws and 
major design problems that are or will become issues, and this would 
be an obvious time to attempt to fix or change them. These include 
minor things such as annoyingly laid-out structures, up to major 
issues such as memory protection and VM. 


Changes to the design does add more compatibility risk. Many of the 
minor ones will cause a few programs to have to change to work, and 

the major ones will often require recompilation and/or a "compatibility 
box" for old programs. 


I think we would be silly not to add VM in some form in the process 

of a port. Protection is harder, given some of the fundamental ways 
our OS works. Quite a few programs could work under protection, but 
probably most complex applications (WP, video, etc) would at least 
require minor changes, and some would require a fair bit of work. 
Strategy games would stand a chance of working, arcade games would 

not work, but they won’t work on a RISC anyways, even with translation/ 
emulation. 


4. 


Other OS’s 


Other OS’s, such as Unix and OS/2, could also take advantage of a RISC 
CPU combined with Amiga graphics/IO chips. We would lose all our 
existing software, at the advantage of getting any software in source 
form (and perhaps binary) for the alternate OS. This can also be a 
good way to provide a platform we could then port the AmigaOS to, 

and an alternate source of sales, leveraging off the same investment 


in chip design (AAA, etc), for the low-end workstation and higher-end 
PC markets. 


this document was 
generously 
contributed by 


randell jesup 


scanned by: 
www.commodore.international 


